Message filtering in a data processing system

ABSTRACT

Each processor of a plurality of processors is configured to execute an interrupt message instruction. A message filtering unit includes storage circuitry configured to store captured identifier information from each processor. In response to a processor of the plurality of processors executing an interrupt message instruction, the processor is configured to provide a message type and a message payload to the message filtering unit. The message filtering unit is configured to use the captured identifier information to determine a recipient processor indicated by the message payload and, in response thereto, provides an interrupt request indicated by the message type to the recipient processor.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is related to U.S. patent application Ser. No. ______(Attorney Docket No. DN30771 NH), filed on even date, entitled “MESSAGEFILTERING IN A DATA PROCESSING SYSTEM,” naming William C. Moyer asinventor, and assigned to the current assignee hereof.

BACKGROUND

1. Field

This disclosure relates generally to data processing systems, and morespecifically, to message filtering in a data processing system.

2. Related Art

In a multiple processor data processing systems, inter-processorinterrupt messaging allows a processor to send an interrupt message toother processors or devices within the data processing system. Forexample, a processor can initiate a message send instruction whichspecifies both a message type and message payload in a general purposeregister. This message is sent to all processors and devices, includingthe sending processor) within a particular domain. Each processor anddevice receives all sent messages and upon receipt of each message, theprocessor or device examines the message type and payload to determinewhether the device or processor should accept the message. If a messageis accepted, the accepting processor or device takes specified actionsbased on the message type. This inter-processor interrupt messagingrequires each processor or device to have the ability to locallydetermine whether a message is accepted. Also, a delivery mechanism isrequired to deliver all messages to all processors and devices. In onesuch system, inter-processor interrupt messaging is performed within amemory coherency domain in which cache coherency snooping mechanisms areused to implement the messaging. However, these cache coherency snoopingmechanisms are not available in all systems. Other systems utilize anindependent distributed messaging interface between multiple processorsin the system. However, this results in increased cost. Therefore, aneed exist for an improved interrupt messaging system.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and is notlimited by the accompanying figures, in which like references indicatesimilar elements. Elements in the figures are illustrated for simplicityand clarity and have not necessarily been drawn to scale.

FIG. 1 illustrates, in block diagram form, a data processing system inaccordance with an embodiment of the present invention.

FIG. 2 illustrates, in block diagram form, a processor of FIG. 1 inaccordance with an embodiment of the present invention.

FIG. 3 illustrates, in block diagram form, a centralized messaging unit(CMU) of FIG. 1 in accordance with an embodiment of the presentinvention.

FIG. 4 illustrates, in diagrammatic form, a message send instruction.

FIG. 5 illustrates, in table form, field descriptions of the fields ofthe message send instruction.

FIG. 6 illustrates, in diagrammatic form, an exemplary logicalpartitioning of a data processing system.

FIG. 7 illustrates, in timing diagram form, signals of system 10 inaccordance with one embodiment of the present invention.

FIG. 8 illustrates, in timing diagram form, signals of system 10 inaccordance with one embodiment of the present invention.

FIG. 9 illustrates, in diagrammatic form, a signaling scheme inaccordance with one embodiment of the present invention.

DETAILED DESCRIPTION

In a multiple processor data processing system, a centralized messagingunit (CMU) is used to control delivery of inter-processor interruptmessages. An inter-processor interrupt message (generated, for example,in response to a message send processor instruction) specifies a messagetype and a message payload. The message type and payload is used todetermine which processor(s) or device(s) should accept the messagebased on information identifiers of each processor, and parameterswithin the message payload. The CMU receives all interrupt messages anddetermines the intended recipient(s) which should accept each message.In order to do so, the CMU samples and captures identifier informationfrom each processor, such as each time a processor updates any of itsidentifier information. The CMU uses this captured identifierinformation to determine the intended recipients for each receivedmessage. The CMU then delivers an interrupt request indicated by themessage type to the appropriate recipient(s). Furthermore, in oneembodiment, messages of the same type to the same recipient within apredetermined interval of time can be coalesced such that a singleinterrupt request representative of multiple accepted messages may bedelivered to the appropriate recipient. Since the CMU performs thefiltering of the messages to determine which recipient(s) should accepta message, a recipient need not perform any additional examination ofthe message to determine whether or not to accept the message.

FIG. 1 illustrates a data processing system 10 having a systeminterconnect 26, a processor 0 12, a processor 1 14, a processor 2 16,and a CMU 20, each bidirectionally coupled to system interconnect 26.System 10 may include any number of other modules 22 and a memory 24.System 10 is illustrated as having three (3) processors, but can haveany number, e.g. one or more, processors. As will be described in moredetail below, CMU 20 is coupled to each of processor 0, processor 1, andprocessor 2 to periodically receive and sample identifier information,and to receive, filter, and then send messages from/to each processor.CMU 20 provides doorbell requests to each of processor 0, processor 1,and processor 2. Each of processor 0, 1, and 2 may send a message toeach processor of system 10 by way of CMU 20. CMU 20, in response to themessages, determines the intended targets and asserts the appropriatedoorbell requests to those intended target(s).

In one embodiment, system 10 is a hypervisor based system whichincorporates the notion of a “logical partition” which is a group ofvirtual (i.e. guest) processor resources. In this embodiment, at anypoint in time, the underlying hardware of system 10 is executinginstructions for the hypervisor, or on behalf of a virtual guestprocessor executing within a logical partition. The hypervisor is alayer of software which lies above the traditional “supervisor” mode ofprivilege level and provides the illusion that the guest supervisor codeis running on a virtual processor of its own, which is identified with aguest processor identifier value.

For example, FIG. 6 illustrates a representation of system 10 as amulti-partitioned hypervisor based system 70. Hypervisor based system 70includes a hypervisor 78 and N logical partitions each having acorresponding logical partition ID (LPID). The logical partitioning isthe subdivision of the physical environment of system 10 into separate,secure logical partitions. The partitions can operate independently ofeach other, and individual physical resources may be either shared, ormay be assigned explicitly to a logical partition, and are managed byhypervisor 78. Each logical partition includes a guest supervisor statewhich runs an operating system within the logical partition, and a guestuser state which includes any number of applications which may beexecuted by the operating system in the logical partition. For example,logical partition 72 has an LPID of 1, and includes a guest supervisorstate which executes an operating system 84 and a guest user state withapplications 82 under control of operating system 84. Note that sinceeach logical partition is independent of each other, each operatingsystem within system 70 may be a different operating system.

Virtualization is the emulation of a virtual machine that is presentedto a logical partition. Virtualization is generally provided by acombination of hardware and software mechanisms. Hypervisor 78 is alow-level software program that presents a virtual machine to anoperating system running in a logical partition. The hypervisor maymanage the multiple virtual machines and logical partitions, even on asingle processor, in a manner analogous to how an operating systemswitches processes.

FIG. 2 illustrates processor 0 12 in accordance with one embodiment ofthe present invention. Processor 0 includes an instruction pipe 30, aninstruction cache 40, a control unit 32, a bus interface unit (BIU) 50,a load/store unit 42, execution units 38, a local bus 44, a data cache46, and a local data memory 48. Instruction pipe 30 is bidirectionallycoupled to instruction cache 40 and control unit 32, load/store unit 42is bidirectionally coupled to control unit 32, execution units 38, andBIU 50. Instruction cache 40 and data cache 46 are each bidirectionallycoupled to BIU 50. Execution units 38 is bidirectionally coupled tocontrol unit 32. Load/store unit 42, data cache 46, and local datamemory 48 are each bidirectionally coupled to local bus 44. Control unit32 includes storage circuitry which stores thread0 identifiers 34 andthread1 identifiers 36. Thread0 identifiers 34 include a processoridentifier register (PIR), a guest processor identifier register (GPIR),and a logical partition identifier register (LPIDR), in which eachregister stores the corresponding identifier for thread0. Thread1identifiers 36 include a PIR, a GPIR, and a LPIDR, in which eachregister stores the corresponding identifier for thread1.

In operation, processor 0 is a multi-threaded processor capable ofexecuting up to two threads, thread0 and thread1. However, in alternateembodiments, processor 0 may be capable of executing more threads, inwhich control unit 32 includes a set of identifier registers, such asidentifiers 34 and 36, for each thread. Instruction pipe 30 fetchesprocessor instructions from instruction cache 40, or, if not presentwithin cache 40, from memory 24 by way of BIU 50. Instruction pipe 30decodes the received instructions and provides them to execution units38 which perform the function indicated by each instruction. Executionunits 38 accesses load/store unit 42 as needed to obtain data or storedata as indicated by an instruction. Load/store unit 42 performs loadsand stores from and to local data memory 48, data cache 46, or memory 24by way of BIU 50.

Referring to thread0 identifiers 34, the PIR register holds theprocessor ID which is used to distinguish physical processors in asystem from one another. Therefore, each PIR register is initialized toa unique value. In the case in which system 10 is a hypervisor basedsystem, each thread also has a corresponding guest processor ID andlogical partition ID. Therefore, in this case, the GPIR holds the guestprocessor ID which is used to distinguish guest processors in a logicalpartition from one another. In a multiprocessor system, like system 10,each GPIR in a logical partition is initialized at partition creationtime by the hypervisor to a unique value in the logical partition. Theguest processor ID may be independent of the PIR contents, and mayrepresent a “virtual” processor ID. The LPIDR holds the logicalpartition ID which is used to distinguish a logical partition from oneanother. The LPIDR can also be initialized at partition creation time bythe hypervisor to a unique value among other logical partitions. Notethat a logical partition may refer to a processor of system 10 or athread of system 10. In the illustrated embodiment, depending on thelogical partitioning, each of thread0 and thread1 is part of a logicalpartition. The same descriptions apply to the PIR, GPIR, and LPIDR ofthread1 identifiers 36.

Processor 0 may execute a message send instruction in either thread0 orthread1, which initiates a message to be sent to another processor, ormay in some instances initiate a message to be sent to itself. FIG. 4illustrates, in diagrammatic form, a message send instruction whichspecifies a message type and a message payload in a general purposeregister (GPR). In the illustrated embodiment, the message type isprovided in bits 32-36 of the specified GPR, and the payload is providedin bits 37-63 of the GPR. Upon execution of a message send instruction,processor 0 sends an interrupt message to CMU 20, containing the messagetype and the message payload. If a message send instruction is executedin thread0, then an interrupt message is sent by way of thread0 messagesto CMU 20, and if a message send is executed in thread1, then aninterrupt message is sent by way of thread1 messages to CMU 20. CMU 20,as will be described in more detail below with respect to FIG. 3,filters these messages based on previously captured values of PIR, GPIR,and LPIDR for each processor thread in system 10.

FIG. 5 illustrates, in table form, various descriptions for the fieldsof the GPR associated with the message send instruction. As indicated intable 5, bits 32-36 identify the message type and may be referred to asthe type field (TYPE). The type of messages encoded by the type fieldcorrespond to doorbell requests. Doorbell requests (also referred to asinterrupt requests) are referred to as such because the message payloadis only used to determine which processor accepts the message. If thetype field is 0, the message type is a processor doorbell request(DBELL). A processor doorbell request generates a processor doorbellinterrupt (i.e. a processor doorbell exception) if the message isaccepted. If the type field is 1, the message type is a processordoorbell critical request (DBELL_CRIT). A processor doorbell criticalrequest generates a processor doorbell critical interrupt (i.e. aprocessor doorbell critical exception) if the message is accepted. ADBELL_CRIT has a higher interrupt priority than a DBELL. If the typefield is a 2, the message type is a guest processor doorbell request(G_DBELL). A guest processor doorbell request generates a guestprocessor doorbell interrupt (i.e. a guest processor doorbell exception)if the message is accepted. If the type field is a 3, the message typeis a guest processor doorbell critical request (G_DBELL_CRIT). A guestprocessor doorbell critical request generates a guest processor doorbellinterrupt (i.e. a guest processor doorbell critical exception) if themessage is accepted. If the type field is a 4, the message type is a isa guest processor doorbell machine check request (G_DBELL_MC). A guestprocessor doorbell machine check request generates a guest processordoorbell machine check exception if the message is accepted. AG_DBELL_CRIT has a higher interrupt priority than a G_DBELL, and aG_DBELL_MC has a higher interrupt priority than a G_DBELL_CRIT. Guestdoorbell requests are targeted to the guest operating system running ona thread (or threads) in a hypervisor-based system. Regular doorbellrequests are targeted to the hypervisor layer of software in ahypervisor-based system, or to a normal operating system layer, in anon-hypervisor system.

Still referring to the table of FIG. 5, bits 37 and 42-63 provide themessage payload. The payload is provided to CMU 20 so that it maydetermine whether a processor should accept a message. The examinationof the payload to determine the appropriate recipients of a message (todetermine which processor(s) should accept a message) is referred to asmessage filtering. Bit 37 of the payload is the broadcast field(BRDCAST). If this field is a 0, the message is not a broadcast. In thiscase, the PIRTAG and LPIDTAG of the message payload are used by CMU 20to determine whether the message should be accepted or not for eachprocessor. If this field is a 1, CMU 20 accepts the message regardlessof the value of PIRTAG if LPIDTAG matches the previously captured LPIDRfor the appropriate processor and thread. Bits 42-49 of the payloadprovide the LPIDTAG. CMU 20 only accepts this message if LPIDTAG of thepayload matches the previously captured LPIDR for the appropriateprocessor and thread, regardless of the values of PIRTAG or BRDCAST.Bits 50-63 of the payload provide the PIRTAG. This field is used toidentify a particular processor. CMU 20 compares the contents of thisfield with the previously captured PIR contents for the appropriateprocessor and thread for DBELL and DBELL_CRIT type message. CMU 20compares the contents of this field with the previously captured GPIRcontents for the appropriate processor and thread for G_DBELL,G_DBELL_CRIT, and G_DBELL_MC type messages. If the PIRTAG matches thepreviously captured PIR (or captured GPIR) for the appropriate processorand thread or BRDCAST is set and LPIDTAG matches the captured LPID forthe appropriate processor and thread, CMU 20 accepts the message onbehalf of the processor. For any accepted message, CMU 20 delivers adoorbell request (i.e. interrupt request) indicated by the message typeof the accepted message to the appropriate recipient processor thread.

In the case in which system 10 is a hypervisor based system, the DBELLand DBELL_CRIT messages are selectively accepted based on both thepreviously captured PIR and LPIDR values for a thread. Furthermore, fora DBELL message type to generate an interrupt on a recipient processoras determined by CMU 20, the processor should have the guest supervisorstate enabled or external exceptions enabled. For a DBELL_CRIT messagetype to generate an interrupt on a recipient processor thread asdetermined by CMU 20, the processor thread should have the guestsupervisor state enabled or critical exceptions enabled. Each of theDBELL and DBELL_CRIT message types are directed to threads of particularprocessors. The G_DBELL, G_DBELL_CRIT, and G_DBELL_MC messages areselectively accepted based on the previously captured LPIDR and GPIRvalues for a thread. Furthermore, for a G_DBELL message type to generatean interrupt on a recipient processor thread as determined by CMU 20,the processor thread should have the guest supervisor state enabled andexternal interrupts enabled. For a G_DBELL_CRIT message type to generatean interrupt on a recipient processor thread as determined by CMU 20,the processor thread should have the guest supervisor state enabled andcritical interrupts enabled. For a G_DBELL_MC message type to generatean interrupt on a recipient processor thread as determined by CMU 20,the processor thread should have the guest supervisor state enabled andmachine check exceptions enabled. Note that G_DBELL, G_DBELL_CRIT, andG_DBELL_MC message types are directed to the hypervisor (e.g. hypervisor78) and will only interrupt when the guest is in execution. Thesemessages are used by the hypervisor software to “reflect”, or emulate aparticular type of asynchronous interrupt (external exception, criticalexception, or machine check exception) to the guest operating system. Ina hypervisor based system, the payload may indicate any target locationby setting the LPIDTAG and PIRTAG accordingly. In this case, the targetlocation may be a particular domain, subsystem, processor, virtualprocessor, etc., depending on how system 10 is partitioned by thelogical partitions and how the hypervisor is implemented.

In the case in which system 10 is not a hypervisor based system, notethat only DBELL and DBELL_CRIT messages are available and are based onlyon the previously captured PIR contents for the appropriate processorand thread. For example, if BRDCAST is enabled, then the message isaccepted regardless of the value of PIRTAG, and if BRDCAST is notenabled, then the message is accepted if PIRTAG matches the previouslycaptured PIR contents. When not a hypervisor based system a targetlocation indicated by the payload may be a processor or virtualprocessor or thread.

In response to a doorbell request, the receiving processor thread canperform one or more predefined actions, such as accessing apredetermined memory location or a shared data structure. In alternateembodiments, different message types may be defined by the message type,including additional types of doorbell requests or other types ofinterrupt requests.

FIG. 3 illustrates, in block diagram form, CMU 20 in accordance with oneembodiment of the present invention. CMU 20 includes filtering logic 60,captured identifiers 62, and sampling and capturing logic 64. Filteringlogic 60 includes message coalesce logic 66 and receives messages fromeach processor in system 10, such as processor 0, processor 1, andprocessor 2. When a processor transmits an interrupt message uponexecution of a send message instruction within a thread, the processorprovides the message type and payload from its GPR to filtering logic 60of CMU 20. Filtering logic 60 may have an input for each thread of aprocessor or may receive a thread identifier with each processormessage. Filtering logic provides doorbell requests (of the varioustypes described above) to each processor of system 10. The doorbellrequests for each processor are specific to a particular thread andtherefore may be provided separately to each processor thread. Forexample, filtering logic may have one output for processor 0 thread 0doorbell requests and another output for processor 0 thread 1 doorbellrequests. Filtering logic is coupled to receive information fromcaptured identifiers 62. Captured identifiers 62 includes storagecircuitry which stores captured identifiers for each thread andprocessor. For example, captured identifiers 62 includes storagecircuitry for processor 0 thread0 identifiers, processor 0 thread1identifiers, processor 1 thread0 identifiers, processor 1 thread1identifiers, processor 2 thread0 identifiers, and processor 2 thread1identifiers. These identifiers may each store the captured PIR, GPIR,and LPIDR values received from each processor for each thread at thetime these values are updated within the processor.

Captured identifiers 62 is coupled to receive sampled and capturedidentifier information from sampling and capturing logic 64. Samplingand capturing logic 64 receives processor 0 identifier information,processor 1 identifier information, and processor 2 identifierinformation. The identifier information can include the PIR, GPIR, andLPIDR values for each thread. For example, processor 0 identifierinformation may include PIR, GPIR, and LPIDR from thread0 identifiers 34of processor 0 and may include PIR, GPIR, and LPIDR from thread1identifiers 36. Each set of identifiers (corresponding to identifiers 34and 36) may be provided independently to CMU 20. In one embodiment,these identifier values from the processors of system 10 are sampledeach time they are updated by the corresponding processor. In thismanner, captured identifiers 62 always store current (up to date)identifier information. For example, if processor 0 updates GPIR orLPIRD of thread1, then the information of thread1 identifiers 36 isprovided to sampling and capturing logic 64. Sampling and capturinglogic 64 then stores this information into the appropriate locationwithin captured identifiers 62. In one embodiment, this identifierinformation is provided to sampling and capturing logic 64 by directsignaling. Alternatively, idle bus transactions may be used, as will bedescribed in more detail below.

Filtering logic 60 of CMU 20 receives messages from the processors ofsystem 10, and uses the captured identifiers and the received payload ofthe messages to determine which processor(s) of system 10 should acceptthe messages. Therefore, filtering logic 60 may include comparators andother logic, as needed, to examine and filter incoming messages todetermine which processors, if any, should accept the message. All sendmessages from the processors of system 10 are filtered by filteringlogic 60. For each received message, filtering logic 60 filters thepayload to determine which processor(s) should accept the message. Foreach processor thread which is determined to accept the message,filtering logic 60 sends an appropriate doorbell request (as indicatedby the message type of the send message) to the processor thread. Notethat the recipient processor of a doorbell request need not perform anyfiltering or examination of the received doorbell requests, because theyare known to be accepted. The determination of acceptance is performedby CMU 20 and not by each individual processor of system 10.

In one embodiment, as described above, for each accepted message, CMU 20delivers a doorbell request to the appropriate processor or processorthread without coalescing accepted messages. In an alternate embodiment,message coalesce logic 66 of CMU 20 may improve doorbell signalingefficiency by coalescing accepted messages of the same message type fora particular processor or processor thread and sending a single doorbellrequest to the recipient processor or processor thread representative ofthe multiple accepted messages. For example, multiple accepted messagesfor a particular processor or processor thread that are of the samemessage type and received within a particular interval of time may becoalesced by message coalesce logic 66 such that a single doorbellrequest can be sent at the end of the particular interval of time.

FIG. 7 illustrates, in timing diagram form, various signals of system 10in accordance to one embodiment which utilizes message coalesce logic66. In FIG. 7, a first message is accepted by filtering logic 60 at timet1. The first accepted message can be from any source within system 10(indicated as source 1), such as, for example, any processor in system10. The first accepted message indicates that a doorbell requestindicated by the message type is to be delivered to an indicatedrecipient processor thread, as was described above. At time t1, counterlogic within message coalesce logic 66 may begin tracking an interval oftime 86. Interval of time 86 may be a predetermined window of time whichis initiated by an accepted message. No doorbell request in response tothe first accepted message is sent until interval 86 is complete. Attime t2, a second message from another source within system 10(indicated as source 2) is accepted by filtering logic 60 withininterval 86. The second accepted message indicates that a doorbellrequest of the same message type as indicated by the first acceptedmessage is to be delivered to a same indicated recipient processorthread as indicated by the first accepted message. Therefore, the firstand second accepted messages can be coalesced by coalesce logic 66 suchthat a single doorbell request can be sent to the indicated recipientprocessor thread representative of both the first and second acceptedmessages. At time t3, interval 86 ends and a single doorbell request isdelivered to recipient processor thread.

Still referring to FIG. 7, at a subsequent time t4, a third message isaccepted by filtering logic 60 from another source within system 10(indicated in source 3). Note that sources 1, 2, and 3 can be differentsources, or any two or all three may be the same source. At time t4,since no interval is currently being tracked, a next interval 88 isstarted by coalesce logic 66. At time t5, interval 88, which may be ofthe same duration as interval 86, ends. Since no other messages of thesame message type for the same recipient processor thread has beenreceived, a doorbell request representative of only the third message isdelivered to the recipient processor thread.

FIG. 8 illustrates, in timing diagram form, various signals of system 10in which the predetermined interval of time in which to coalescemessages is truncated in response to a broadcast message. In the exampleof FIG. 8, at time t1 a first message from any source (indicated assource 1) intended for a thread of processor 0 is accepted by filterlogic 60. Coalesce logic 66 begins interval of time 92. At time t2, asecond message from any source (indicated as source 2) intended for thesame thread of processor 0 and of the same message type as the acceptedfirst message. Therefore, coalesce logic 66 can coalesce both the firstand second accepted messages and respond to the indicated thread ofprocessor 0 with a single doorbell request at the end of interval 92.However, at time t3, a broadcast message is received from any source(indicated as source 3) and is accepted on behalf of all processors.Note that sources 1, 2, and 3 can be different sources, or any two orall three may be the same source. Due to the acceptance of a broadcastmessage, interval 92 is truncated prior to completion of the fullinterval, resulting in a shortened interval 90. That is, acceptance of abroadcast message reduces the duration of the initial interval. Afterthe end of truncated interval 90, at time t4, a single doorbell requestis sent to the indicated recipient processor thread representative ofboth the first and second accepted messages. At time t5, a doorbellrequest in response to the accepted broadcast message is sent to each ofprocessors 0, 1, and 2. The doorbell requests to each of processors 0,1, and 2 are sent simultaneously to each other, or substantiallysimultaneously with each other (such as within a small amount of time ofeach other.) Without CMU 20, a broadcast message would be sent to eachrecipient processor independently for filtering and thus the broadcastsmay not actually be received or accepted simultaneously. However, withCMU 20 filtering all messages in system 10, CMU 20 can filter abroadcast message and broadcast doorbell requests such that eachrecipient may receive them simultaneously or substantiallysimultaneously.

Still referring to FIG. 8, note that times t4 and t5 occur after t3(which corresponds to the end of truncated interval 92) in which thedoorbell request at time t4 is delivered in response to the coalescedmessages and the doorbell requests at time t5 are delivered in responseto the broadcast message. Alternatively, t4 may occur after t5.Furthermore, in one embodiment, the doorbell requests in response to thebroadcast message to each of processors 0, 1, and 2 may be sent atdifferent times and in any order. Time t6 in FIG. 8 corresponds to theend of interval 92 had it not been truncated or shortened in response tothe accepted broadcast message.

In one embodiment, the send messages from the processors are sent to CMU20 via direct signaling. In an alternate embodiment, CMU 20 monitors“send message” operations on system interconnect 26 which are disguisedas an IDLE bus transaction, and then distributes processor doorbellmessage interrupts via hardwired doorbell request signals, based on theappropriate filtering rules for the doorbell message. Note that aninterrupt controller of a processor is not involved in these operationsof receiving send messages, filtering send messages, and directing anddelivering doorbell requests.

As illustrated in FIG. 1, update and messaging information can beprovided directly from each processor in system 10 to CMU 20, and not byway of system interconnect 26. However, in an alternate embodiment,extended signaling may be used to provide this type of information byway of system interconnect 26. In one embodiment, IDLE bus cycles onsystem interconnect 26 may be used to disguise both message payloads andupdate values. FIG. 9 illustrates a table with extended signaling forsystem interconnect 26. For each bus transaction on system interconnect26, a value can be provided for an address bus, a transfer size, a writedata bus, a write data strobes, and a transfer type. In one embodiment,the transfer size being set to 00, 01, 10, or 11 indicates that amessage payload or an update value is being provided by way of an IDLEbus cycle. Therefore, CMU 20 can monitor bus transactions until one ofthese extended IDLE bus cycles is detected. For example, with a transfersize of 00 or 01, the target locations and message payload may beprovided for a targeted message or broadcast message, respectively. Witha transfer size of 10, the write data bus may provide the PIR, GPIRupdate values for a particular physical processor and thread ID on theaddress bus. With a transfer size of 11, the write data bus may providethe LPIDR update value for a particular physical processor ID on theaddress bus. In this manner, these messaging operations can be overlaidonto an existing bus protocol through the use of IDLE bus transactions.This prevents the need for direct signaling lines.

Therefore, by now it can be understood how a centralized filtering unitmay be used to implement inter-processor interrupt messaging. Thecentralized filtering unit may sample and capture identifier informationto ensure that the most current identifier information is stored foreach processor. Each interrupt message is sent to the centralizedfiltering unit so that it may filter the message by examining themessage payload and using the previously captured and stored identifierinformation. Upon determining the intended one or more recipients of amessage, the centralized filter unit delivers the appropriate interruptrequest, such as a doorbell request, to the one or more intendedrecipients. Furthermore, in one embodiment, accepted messages of thesame type to the same recipient within a predetermined interval of timecan be coalesced such that a single interrupt request representative ofmultiple accepted messages may be delivered to the appropriaterecipient. Note that a recipient can be a processor, a processor thread,logical partition, guest processor, etc. Also, the recipient need notfurther examine or filter the messages or interrupt requests since theyhave already been determined as accepted by the centralized filteringunit for the recipient.

As used herein, the term “bus” is used to refer to a plurality ofsignals or conductors which may be used to transfer one or more varioustypes of information, such as data, addresses, control, or status. Theconductors as discussed herein may be illustrated or described inreference to being a single conductor, a plurality of conductors,unidirectional conductors, or bidirectional conductors. However,different embodiments may vary the implementation of the conductors. Forexample, separate unidirectional conductors may be used rather thanbidirectional conductors and vice versa. Also, plurality of conductorsmay be replaced with a single conductor that transfers multiple signalsserially or in a time multiplexed manner. Likewise, single conductorscarrying multiple signals may be separated out into various differentconductors carrying subsets of these signals. Therefore, many optionsexist for transferring signals.

The terms “assert” or “set” and “negate” (or “deassert” or “clear”) areused herein when referring to the rendering of a signal, status bit, orsimilar apparatus into its logically true or logically false state,respectively. If the logically true state is a logic level one, thelogically false state is a logic level zero. And if the logically truestate is a logic level zero, the logically false state is a logic levelone.

Each signal described herein may be designed as positive or negativelogic, where negative logic can be indicated by a bar over the signalname or an asterix (*) following the name. In the case of a negativelogic signal, the signal is active low where the logically true statecorresponds to a logic level zero. In the case of a positive logicsignal, the signal is active high where the logically true statecorresponds to a logic level one. Note that any of the signals describedherein can be designed as either negative or positive logic signals.Therefore, in alternate embodiments, those signals described as positivelogic signals may be implemented as negative logic signals, and thosesignals described as negative logic signals may be implemented aspositive logic signals.

Because the apparatus implementing the present invention is, for themost part, composed of electronic components and circuits known to thoseskilled in the art, circuit details will not be explained in any greaterextent than that considered necessary as illustrated above, for theunderstanding and appreciation of the underlying concepts of the presentinvention and in order not to obfuscate or distract from the teachingsof the present invention.

Moreover, the terms “front,” “back,” “top,” “bottom,” “over,” “under”and the like in the description and in the claims, if any, are used fordescriptive purposes and not necessarily for describing permanentrelative positions. It is understood that the terms so used areinterchangeable under appropriate circumstances such that theembodiments of the invention described herein are, for example, capableof operation in other orientations than those illustrated or otherwisedescribed herein.

Some of the above embodiments, as applicable, may be implemented using avariety of different information processing systems. For example,although FIG. 1 and the discussion thereof describe an exemplaryinformation processing architecture, this exemplary architecture ispresented merely to provide a useful reference in discussing variousaspects of the invention. Of course, the description of the architecturehas been simplified for purposes of discussion, and it is just one ofmany different types of appropriate architectures that may be used inaccordance with the invention. Those skilled in the art will recognizethat the boundaries between logic blocks are merely illustrative andthat alternative embodiments may merge logic blocks or circuit elementsor impose an alternate decomposition of functionality upon various logicblocks or circuit elements.

In one embodiment, the illustrated elements of system 10 are circuitrylocated on a single integrated circuit or within a same device.Alternatively, system 10 may include any number of separate integratedcircuits or separate devices interconnected with each other.

Furthermore, those skilled in the art will recognize that boundariesbetween the functionality of the above described operations merelyillustrative. The functionality of multiple operations may be combinedinto a single operation, and/or the functionality of a single operationmay be distributed in additional operations. Moreover, alternativeembodiments may include multiple instances of a particular operation,and the order of operations may be altered in various other embodiments.

Although the invention is described herein with reference to specificembodiments, various modifications and changes can be made withoutdeparting from the scope of the present invention as set forth in theclaims below. For example, system 10 may be a hypervisor based system ormay not implement a hypervisor. Accordingly, the specification andfigures are to be regarded in an illustrative rather than a restrictivesense, and all such modifications are intended to be included within thescope of the present invention. Any benefits, advantages, or solutionsto problems that are described herein with regard to specificembodiments are not intended to be construed as a critical, required, oressential feature or element of any or all the claims.

The term “coupled,” as used herein, is not intended to be limited to adirect coupling or a mechanical coupling.

Furthermore, the terms “a” or “an,” as used herein, are defined as oneor more than one. Also, the use of introductory phrases such as “atleast one” and “one or more” in the claims should not be construed toimply that the introduction of another claim element by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim element to inventions containing only one such element,even when the same claim includes the introductory phrases “one or more”or “at least one” and indefinite articles such as “a” or “an.” The sameholds true for the use of definite articles.

Unless stated otherwise, terms such as “first” and “second” are used toarbitrarily distinguish between the elements such terms describe. Thus,these terms are not necessarily intended to indicate temporal or otherprioritization of such elements.

The following are various embodiments of the present invention.

In one embodiment, a data processing system includes a systeminterconnect; a plurality of processors coupled to the systeminterconnect, each of the plurality of processors configured to executea plurality of instructions, including a message send instruction; and amessage filtering unit coupled to the system interconnect, wherein themessage filtering unit comprises storage circuitry configured to storecaptured identifier information from each processor of the plurality ofprocessors. In response to a processor of the plurality of processorsexecuting a message send instruction, the processor is configured toprovide a message type and a message payload to the message filteringunit, and the message filtering unit is configured to use the capturedidentifier information to determine a recipient processor indicated bythe message payload and, in response thereto, provides an interruptrequest indicated by the message type to the recipient processor. In oneaspect of the above embodiment, each processor is configured to storeidentifier information and provide updated identifier information to thefiltering unit when an update of the stored identifier information isperformed by the processor. In a further aspect, the updated identifierinformation is stored as captured identifier information for theprocessor in the storage circuitry. In another further aspect, eachprocessor is configured to transmit the stored identifier information tothe filtering unit on the system interconnect using an idle bustransaction when an update of the stored identifier information occurs.In another further aspect, each processor is a multi-threaded processorconfigured to execute a first thread and a second thread, wherein thestored identifier information comprises a first set of identifierinformation corresponding to the first thread and a second set ofidentifier information corresponding to the second thread. In yet afurther aspect, the message type and message payload provided by theprocessor to the message filtering unit corresponds to the first threador the second thread, based on which thread executed the interruptmessage instruction. In yet an even further aspect, the interruptrequest provided by the filtering unit corresponds to the thread whichexecuted the message send instruction. In another aspect of the aboveembodiment, the data processing system is a hypervisor based system, andthe captured identifier information comprises at least one of a logicalpartition identifier and a guest processor identifier. In a furtheraspect, the captured identifier information further comprises aprocessor identifier. In another aspect of the above embodiment, thecaptured identifier information comprises a processor identifier. Inanother aspect of the above embodiment, the processor is configured totransmit the message type and message payload over the systeminterconnect as an idle bus transaction. In yet another aspect of theabove embodiment, the message filtering unit is external to theplurality of processors.

In another embodiment, a data processing system is configured as ahypervisor based system having a plurality of logical partitions, eachlogical partition having a corresponding guest processor. The dataprocessing system includes a plurality of processors, each processorconfigured to store a logical partition identifier corresponding to alogical partition of the plurality of logical partitions and a guestprocessor identifier and configured to execute a plurality ofinstructions, including a message send instruction; and a messagefiltering unit coupled to the system interconnect and comprising storagecircuitry configured to store a captured logical partition identifierand a captured guest processor identifier for each processor of theplurality of processors. In response to a processor of the plurality ofprocessors executing a message send instruction, the processor isconfigured to provide a message type and a message payload to themessage filtering unit, and the message filtering unit is configured touse the captured local partition identifier and the captured guestprocessor identifier to determine a recipient processor of the pluralityof processors as indicated by the message payload and, in responsethereto, provide an interrupt request indicated by the message type tothe recipient processor. In one aspect of the another embodiment, eachprocessor is configured to provide an updated logical partitionidentifier to the message filtering unit when the logical partitionidentifier is updated by the processor, and wherein the updated logicalpartition identifier is stored as the captured local partitionidentifier by the message filtering unit. In another aspect, eachprocessor is configured to provide an updated guest processor identifierto the message filtering unit when the guest processor identifier isupdated by the processor, and wherein the updated guest processoridentifier is stored as the captured guest processor identifier by themessage filtering unit. In another aspect, each processor is configuredto transmit the stored identifier information to the filtering unit onthe system interconnect using an idle bus transaction when an update ofthe stored identifier information. In yet another aspect, each processoris a multi-threaded processor configured to execute a first thread and asecond thread, wherein the stored logical partition identifier and guestprocessor identifier correspond to the first thread, and wherein eachprocessor is configured to store a second logical partition identifiercorresponding to the second thread and a second guest processoridentifier corresponding to the second thread. In a further aspect ofthe yet another aspect, the message type and message payload provided bythe processor to the message filtering unit corresponds to the firstthread or the second thread, based on which thread executed theinterrupt message instruction, and the interrupt request provided by thefiltering unit corresponds to the thread which executed the message sendinstruction.

In yet another embodiment of the present invention, a method in a dataprocessing system having a plurality of processors and a messagefiltering unit, each processor configured to store correspondingidentifier information, includes capturing, by the message filteringunit, the identifier information corresponding to each processor,wherein each time a processor updates its corresponding identifierinformation, the message filtering unit updates the captured identifierinformation for the processor; receiving a message type and messagepayload from a processor of the plurality of processors in response tothe processor executing a message send instruction; determining, by themessage filtering unit, one or more recipient processors using thecaptured identifier information and the message payload; and providing,by the message filtering unit to the one or more recipient processors,an interrupt request indicated by the message type. In one aspect of theyet another embodiment, the data processing system is a hypervisor basedsystem, and the captured identifier information comprises a processoridentifier, a logical partition identifier, and a guest processoridentifier.

What is claimed is:
 1. A data processing system, comprising: a systeminterconnect; a plurality of processors coupled to the systeminterconnect, each of the plurality of processors configured to executea plurality of instructions, including a message send instruction; and amessage filtering unit coupled to the system interconnect, wherein themessage filtering unit comprises storage circuitry configured to storecaptured identifier information from each processor of the plurality ofprocessors, and wherein: in response to a processor of the plurality ofprocessors executing a message send instruction, the processor isconfigured to provide a message type and a message payload to themessage filtering unit, and the message filtering unit is configured touse the captured identifier information to determine a recipientprocessor indicated by the message payload and, in response thereto,provides an interrupt request indicated by the message type to therecipient processor.
 2. The data processing system of claim 1, whereineach processor is configured to store identifier information and provideupdated identifier information to the filtering unit when an update ofthe stored identifier information is performed by the processor.
 3. Thedata processing system of claim 2, wherein the updated identifierinformation is stored as captured identifier information for theprocessor in the storage circuitry.
 4. The data processing system ofclaim 2, wherein each processor is configured to transmit the storedidentifier information to the filtering unit on the system interconnectusing an idle bus transaction when an update of the stored identifierinformation occurs.
 5. The data processing system of claim 2, whereineach processor is a multi-threaded processor configured to execute afirst thread and a second thread, wherein the stored identifierinformation comprises a first set of identifier informationcorresponding to the first thread and a second set of identifierinformation corresponding to the second thread.
 6. The data processingsystem of claim 5, wherein the message type and message payload providedby the processor to the message filtering unit corresponds to the firstthread or the second thread, based on which thread executed theinterrupt message instruction.
 7. The data processing system of claim 6,wherein the interrupt request provided by the filtering unit correspondsto the thread which executed the message send instruction.
 8. The dataprocessing system of claim 1, wherein the data processing system is ahypervisor based system, and the captured identifier informationcomprises at least one of a logical partition identifier and a guestprocessor identifier.
 9. The data processing system of claim 8, whereinthe captured identifier information further comprises a processoridentifier.
 10. The data processing system of claim 1, wherein thecaptured identifier information comprises a processor identifier. 11.The data processing system of claim 1, the processor is configured totransmit the message type and message payload over the systeminterconnect as an idle bus transaction.
 12. The data processing systemof claim 1, wherein the message filtering unit is external to theplurality of processors.
 13. A data processing system configured as ahypervisor based system having a plurality of logical partitions, eachlogical partition having a corresponding guest processor, the dataprocessing system comprising: a plurality of processors, each processorconfigured to store a logical partition identifier corresponding to alogical partition of the plurality of logical partitions and a guestprocessor identifier and configured to execute a plurality ofinstructions, including a message send instruction; and a messagefiltering unit coupled to the system interconnect and comprising storagecircuitry configured to store a captured logical partition identifierand a captured guest processor identifier for each processor of theplurality of processors, wherein: in response to a processor of theplurality of processors executing a message send instruction, theprocessor is configured to provide a message type and a message payloadto the message filtering unit, and the message filtering unit isconfigured to use the captured local partition identifier and thecaptured guest processor identifier to determine a recipient processorof the plurality of processors as indicated by the message payload and,in response thereto, provide an interrupt request indicated by themessage type to the recipient processor.
 14. The data processing systemof claim 13, wherein each processor is configured to provide an updatedlogical partition identifier to the message filtering unit when thelogical partition identifier is updated by the processor, and whereinthe updated logical partition identifier is stored as the captured localpartition identifier by the message filtering unit.
 15. The dataprocessing system of claim 13, wherein each processor is configured toprovide an updated guest processor identifier to the message filteringunit when the guest processor identifier is updated by the processor,and wherein the updated guest processor identifier is stored as thecaptured guest processor identifier by the message filtering unit. 16.The data processing system of claim 13, wherein each processor isconfigured to transmit the stored identifier information to thefiltering unit on the system interconnect using an idle bus transactionwhen an update of the stored identifier information.
 17. The dataprocessing system of claim 13, wherein each processor is amulti-threaded processor configured to execute a first thread and asecond thread, wherein the stored logical partition identifier and guestprocessor identifier correspond to the first thread, and wherein eachprocessor is configured to store a second logical partition identifiercorresponding to the second thread and a second guest processoridentifier corresponding to the second thread.
 18. The data processingsystem of claim 17, wherein the message type and message payloadprovided by the processor to the message filtering unit corresponds tothe first thread or the second thread, based on which thread executedthe interrupt message instruction, and the interrupt request provided bythe filtering unit corresponds to the thread which executed the messagesend instruction.
 19. In a data processing system having a plurality ofprocessors and a message filtering unit, each processor configured tostore corresponding identifier information, a method comprising:capturing, by the message filtering unit, the identifier informationcorresponding to each processor, wherein each time a processor updatesits corresponding identifier information, the message filtering unitupdates the captured identifier information for the processor; receivinga message type and message payload from a processor of the plurality ofprocessors in response to the processor executing a message sendinstruction; determining, by the message filtering unit, one or morerecipient processors using the captured identifier information and themessage payload; and providing, by the message filtering unit to the oneor more recipient processors, an interrupt request indicated by themessage type.
 20. The method of claim 19, wherein the data processingsystem is a hypervisor based system, and the captured identifierinformation comprises a processor identifier, a logical partitionidentifier, and a guest processor identifier.